Machine to Machine (M2M) techniques refer to all techniques for establishing a connection between machines. The M2M concept arose in the 1990's but was only in its theoretical stage then. After 2000, as the development of mobile communication techniques, it becomes possible to realize networking of machines through mobile communication techniques. M2M services were launched into the market in about 2002 and developed rapidly thereafter, thus becoming a focus of attention of many communication equipment manufacturers and telecommunication operators. At present machines in the world are much more than people therein, thus it can be foreseen that M2M techniques will have good market prospects.
Studies on application scenarios of M2M communications show that there are huge market prospects in providing M2M communications using a mobile network. But M2M services make many new requirements on a communication system. Therefore, in order to make a mobile network more competitive in this regard, it is necessary to optimize an existing network so as to support M2M communications more efficiently.
An existing mobile communication network is designed mainly for communications among people, which is less optimized for communications between man and machine. In addition, how an operator can provide M2M communication services at a low cost is also critical to a successful deployment of M2M communications.
Based on above conditions, it is necessary to study technical solutions for a mobile network to support M2M communications so as to re-use existing networks to the greatest extent, thus decreasing influences caused by a large amount of M2M communications on a network and lowering the complexity of operation and maintenance.
Current competition in the telecommunication market becomes increasingly intense, profit margins for an operator become ever-shrinking with a continuous decrease in charges, and the people-oriented communication market is becoming saturated, thus M2M means a totally new opportunity for development to operators.
In order to efficiently use mobile network resources, the 3rd Generation Partnership Project (3GPP) proposes the Machine Type Communication (MTC), i.e., Machine to Machine (M2M) and machine to man communication services, with its service scope beyond that of existing Human to Human (H2H) communications, and the MTC differs greatly from an existing H2H communication model in aspects such as access control, charging, security, Quality of Service (QoS), service mode and the like.
In a 3GPP Evolved Packet System (EPS) architecture, the EPS includes a radio access network (such as a UTMS Universal Terrestrial Radio Access Network (UTRAN), an Evolved UTRAN (E-UTRAN), a GSM/EDGE Radio Access Network (GERAN)) and a core network, e.g., an Evolved Packet Core (EPC) including network elements such as a Mobility Management Entity (MME), a serving gateway, a Packet Data Network (PDN) Gateway (PGW) and the like, and a GPRS core including network elements such as a Serving GPRS Support Node (SGSN) and the like; the E-UTRAN includes an evolved Node B (eNB).
Triggering of an MTC device (also called MTC Device Trigger) is one of basic requirements on an MTC system, and a problem concerned by the requirement is that communications can be implemented by the way that an MTC server initiates a polling in order to control communications of an MTC device, and with respect to communications initiated by the MTC device, the MTC server may be desired at times to poll data from the MTC device. If the MTC server makes an unsuccessful query or an IP address of the MTC device is not available, the MTC server may establish communications with the MTC device through MTC device trigger. If a network cannot trigger the MTC device, the network reports to the MTC server an MTC device trigger failure, the MTC device trigger is implemented through control plane signaling in the 3GPP.
The MTC device trigger includes a Mobile Originated (MO) service and a Mobile Terminating (MT) service, i.e., including transmitting or receiving information by the MTC device.
In order to implement efficient transmission of an MTC device trigger request, the proposed solutions include transmitting trigger information about the MTC device through a Short Messaging Service (SMS), or transmitting the trigger information about the MTC device through control plane signaling or transmitting the trigger information about the MTC device through user plane data. For the way of transmitting the trigger information about the MTC device through control plane signaling, an MTC server transmits control plane signaling including the trigger information about the MTC device to an MTC Inter Working Function (MTC-IWF), the MTC-IWF chooses to transmit the trigger information through a T5 or T4 interface, and then transmits the trigger information about the MTC device to User Equipment (UE). For the way of transmitting the trigger information about the MTC device through user plane data, the MTC server transmits the trigger information about the MTC device to the MTC-IWF, the MTC-IWF acquires an IP address of the MTC device and transmits the trigger information to the MTC device through a user plane. FIG. 1 is a schematic diagram of an MTC architecture in the 3GPP according to the prior art, as shown in FIG. 1, in the user plane, an MTC application device connected to an MTC user communicates with an MTC server through an API, or communicates directly with a Gateway GPRS Support Node (GGSN)/PGW in a 3GPP network through a Gi/SGi interface; the MTC server communicates with the GGSN/PGW through a Gi/SGi interface; the GGSN/PGW communicates with UE through a Radio Access Network (RAN); in the control plane, an MTC server transmits control plane signaling including the trigger information about the MTC device to an MTC-IWF through a Tsp interface, and the MTC-IWF transmits the control plane signaling to an MME/SGSN/MSC (Mobile Switching Center) or SM-SC (Short Message Service Center) so as to be transmitted to the UE through the RAN.
A Mobile Application Part (MAP) protocol defines a signaling system and regulations of an application layer of a system of a 3GPP core network, and the MAP protocol provides a mobility service, an operation maintenance service, a call processing service, a supplementary services related service, an SMS management service, a Packet Data Protocol (PDP) context activation service for a network request and a management service for positioning services. The MAP protocol applies to interfaces between various functional entities of the core network, including C, D, E, F, G, J, Gc, Gd, Gf and Gr.
The Authentication, Authorization and Accounting (AAA) working group of the Internet Engineering Task Force (IETF) agrees to regard the Diameter protocol as a standard of an AAA protocol of next generation. The Diameter protocol (the upgraded version of the RADIUS protocol) includes Base protocols, a Network Access Service (NAS) protocol, an Extensible Authentication Protocol (EAP), a Mobile IP Protocol (MIP), a Cryptographic Message Syntax (CMS) protocol and the like. The Diameter protocol supports the authentication, authorization and accounting of a mobile IP, an NAS request and a mobility agent, and the Diameter protocol is implemented in a similar way as the Remote Authentication Dial In User Service (RADIUS), also implemented using an Attribute-Length-Value (AVP) triple and an attribute value pair (in the form of Attribute-Length-Value), but the Diameter protocol further specifies in detail an error processing mechanism, a failover mechanism, the use of a Transmission Control Protocol (TCP) and the support to distributed accounting, thus overcoming many drawbacks of the RADIUS and becoming an AAA protocol most suitable for future mobile communication systems.
In the 3GPP during a period when circuit switched services predominate (e.g., Global System of Mobile communication (GSM)), an interface of a core network generally uses the MAP protocol, and with the development of packet switching (e.g., Long Term Evolution (LTE)), an interface of a core network generally uses the Diameter protocol. For example, a Home Location Register (HLR) generally uses the MAP protocol while an MME generally uses the Diameter protocol, thus when the MME is connected to the HLR, it is needed to perform conversion between the MAP protocol and the Diameter protocol and an IWF is used to implement the protocol conversion. FIG. 2 is a schematic diagram showing inter-working of network elements of a mobile network through the IWF, as shown in FIG. 2, the IWF is in charge of protocol conversion between the MAP and the Diameter.
In the 3GPP, Tsp and S6m interfaces use the Diameter protocol and a T4 interface may also use the Diameter protocol, while the HLR may be deployed in an MTC architecture and generally uses the MAP protocol.
During the study and implementation of the prior art, it is found that there are problems left unsolved hitherto in the prior art, i.e., when an MTC-IWF transmits trigger information through a T4 interface, if an SMS related entity (such as SM-SC, GMSC, IWMSC, SMS Router) interworks with an HLR using the MAP protocol while an MME, Tsp and S6m interwork with each other using the Diameter protocol, it is not clear how to implement conversion between the MAP protocol and the Diameter protocol and which network entity is expected to perform the conversion during cooperative communication of above network elements, and if SMS in MME is supported, it is not clear which protocol will be used between network entities of an SMS core network.